Streamlined provisioning system and method

ABSTRACT

In one embodiment, a computer-implemented method may include creating one or more objects in response to a trigger event, converting the one or more objects to a provisioning message, and determining whether the provisioning message includes a request for an identity or an account using one or more rule calls. The computer-implemented method may also include, when the request is for the identity, determining a type of entity to provision and application accounts to provision for the entity using one or more rule calls, and when the request is for the account, determining which application accounts to provision for the entity using one or more rule calls. Further, computer-implemented method may include provisioning the application accounts for the entity as determined.

BACKGROUND

The present disclosure relates generally to managing data and/ortechnology resources, and, more particularly, to streamlining theprovisioning and de-provisioning of data and/or technology resources toentities using a common enrichment process.

As used herein, provisioning refers to providing entities (e.g., users,clients, and/or customers) with access to data and/or technologyresources and de-provisioning refers to removing and/or disabling entity(e.g., user, client and/or customer) access to data and/or technologyresources. Also, the term “technology resources” may refer to technologyrelated systems, such as: software applications, databases, networks,file directories, data feeds, and so forth.

This section is intended to introduce the reader to various aspects ofart that may be related to various aspects of the present techniques,which are described and/or claimed below. This discussion is believed tobe helpful in providing the reader with background information tofacilitate a better understanding of the various aspects of the presentdisclosure. Accordingly, it should be understood that these statementsare to be read in this light, and not as admissions of prior art.

Organizations typically use a diverse set of technology resources (e.g.,information-technology (IT) systems, software applications, networks,and/or databases) to run their businesses, manage employees,contractors, customers, etc., communicate with third-parties, and soforth. Oftentimes, it is a cumbersome task to manage account, group, andidentity objects across the diverse set of technology resources. Rulesmay be used that provide entities, such as employees or contractors,with different accounts and/or access rights to different technologyresources. For example, an employee may be provisioned read and writeaccess rights to an internal file share system, whereas a contractor mayonly be provisioned access rights to read from the internal file sharesystem. In some instances, an entity that already exists in a system maybe provisioned additional technology resources, such as an account to asoftware application, or the like. In another slightly more complicatedexample, an employee may be converted to a contractor, therebynecessitating de-provisioning certain technology resources and/orprovisioning different technology resources. As may be appreciated, asmore technology resources and/or entities are added and/or removed fromthe organizations, the rules that govern the provisioning andde-provisioning of technology resources to the entities may beduplicated and become unmanageable.

BRIEF DESCRIPTION

Certain embodiments commensurate in scope with the originally claimedsubject matter are summarized below. These embodiments are not intendedto limit the scope of the claimed subject matter, but rather theseembodiments are intended only to provide a brief summary of possibleforms of the subject matter. Indeed, the subject matter may encompass avariety of forms that may be similar to or different from theembodiments set forth below.

In one embodiment, a computer-implemented method may include creatingone or more objects in response to a trigger event, converting the oneor more objects to a provisioning message, and determining whether theprovisioning message includes a request for an identity or an accountusing one or more rule calls. The computer-implemented method may alsoinclude, when the request is for the identity, determining a type ofentity to provision and application accounts to provision for the entityusing one or more rule calls, and when the request is for the account,determining which application accounts to provision for the entity usingone or more rule calls. Further, computer-implemented method may includeprovisioning the application accounts for the entity as determined.

In one embodiment, a system may include a processor-based workstation, aprocessor-based provisioning system, and one or more data sources,technology resources, or both. The processor-based provisioning systemmay be configured to create one or more objects in response to a triggerevent activated by the processor-based workstation, convert the one ormore objects to a provisioning message, determine whether theprovisioning message includes a request for an identity or an accountfor the one or more data sources, technology resources, or both usingone or more rule calls. When the request is for the identity, theprocessor-based provisioning system may be configured to determine atype of entity to provision and accounts, access rights, or both for theone or more data sources, technology resources, or both to provision forthe entity using one or more rule calls. When the request is for theaccount for the one or more data sources, technology resources, or both,the processor-based provisioning system may be configured to determinewhich of the one or more data sources, technology resources, or bothaccounts, access rights, or both to provision for the entity using oneor more rule calls. Further, the processor-based provisioning system maybe configured to provision the one or more data sources, technologyresources, or both accounts, access rights, or both for the entity asdetermined.

In one embodiment, a processor-based device may be configured to createone or more objects in response to a trigger event, convert the one ormore objects to a provisioning message, and determine whether theprovisioning message includes a request for an identity or an accountusing one or more rule calls. When the request is for the identity, theprocessor-based device may be configured to determine a type of entityto provision and accounts to provision for the entity using one or morerule calls. When the request is for the account, the processor-baseddevice may be configured to determine which of the accounts to provisionfor the entity using one or more rule calls. Further, theprocessor-based device may be configured to provision the accounts forthe entity as determined.

DRAWINGS

These and other features, aspects, and advantages of the presentdisclosure will become better understood when the following detaileddescription is read with reference to the accompanying drawings in whichlike characters represent like parts throughout the drawings, wherein:

FIG. 1 is a schematic view of a provisioning system, in accordance withan embodiment;

FIG. 2 is a flowchart illustrating a provisioning process using thesystem of FIG. 1, in accordance with an embodiment;

FIG. 3 is a schematic view illustrating a more detailed view of theprovisioning system of FIG. 1, in accordance with an embodiment;

FIGS. 4A and 4B is a schematic view of a provisioning system thatincludes a rule based engine and a message enrichment process, inaccordance with an embodiment; and

FIG. 5 is a flowchart illustrating a process for provisioning dataand/or technology resources using the system of FIGS. 4A and 4B, inaccordance with an embodiment.

DETAILED DESCRIPTION

One or more specific embodiments of the present disclosure will bedescribed below. In an effort to provide a concise description of theseembodiments, all features of an actual implementation may not bedescribed in the specification. It should be appreciated that in thedevelopment of any such actual implementation, as in any engineering ordesign project, numerous implementation-specific decisions must be madeto achieve the developers' specific goals, such as compliance withsystem-related and business-related constraints, which may vary from oneimplementation to another. Moreover, it should be appreciated that sucha development effort might be complex and time consuming, but wouldnevertheless be a routine undertaking of design, fabrication, andmanufacture for those of ordinary skill having the benefit of thisdisclosure.

When introducing elements of various embodiments of the presentdisclosure, the articles “a,” “an,” “the,” and “said” are intended tomean that there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements. Itshould be noted that the term “entity” refers to a user of one or moretechnology resources, such as: an employee, customer, contractor, orpartner, or a computer system, web service, or the like. In somescenarios, “entity” may refer to a group or subset of users of one ormore technology resources. Also, the term “technology resources” refersto technology related systems (e.g., software applications, databases,networks, file directories, feeds, and so forth). Provisioning refers toproviding entities (e.g., users, clients, and/or customers) with accessto data and/or technology resources and de-provisioning refers toremoving and/or disabling entity (e.g., user, client, and/or customer)access to data and/or technology resources.

As previously mentioned, there exists an opportunity to more easilyfacilitate the provisioning and de-provisioning of data and/ortechnology resources associated with entities. For example, streamliningthe process for creating and/or configuring software applicationaccounts and access rights for new and existing employees, contractors,customers, and so forth, may be highly desirable. Accordingly, FIG. 1 isa schematic view of a system 10 for provisioning data, in accordancewith an embodiment. The system 10 may streamline and simplify theprovisioning and de-provisioning of data and/or technology resourcesassociated with entities by enabling a standardized process to enrichinitial provisioning data with various details (e.g., requester, owner,and object type) within the provisioning data prior to execution offunction calls against the technology resources. FIG. 2 is a flowchartillustrating a provisioning process 30 using the system 10 of FIG. 1, inaccordance with an embodiment. For clarity, FIGS. 1 and 2 will bediscussed together.

The system 10 may include one or more workstations, a provisioningsystem 14, and one or more applications 16 or other technologyresources. The workstations 12 may include an interactive console, suchas a personal computer, laptop, terminal, and the like. The provisioningsystem 14 may be located on a server and may be accessed by theworkstations 12 that serve as clients in a client-server architecture.The provisioning system 14 includes a non-transitory, machine-readablemedium (e.g., flash storage, etc.) that may store machine-readableinstructions to complete the process tasks described herein. In someembodiments, various aspects of the provisioning system 14 may bedistributed among more than one server to enhance processing speed.

The workstations 12 may communicate with the provisioning system 14 viaa wired (Ethernet) connection or wireless connection using any suitablewireless communication standard, such as Wi-Fi, ZigBee®, Bluetooth®, andso forth. In some embodiments, entities may be introduced, modified,and/or removed from the system 10. For example, a user in humanresources (HR) may use the workstation 12 to add a new employee, modifyaccounts for technology resources for an existing employee, or deletethe employee's information and accounts from an organization. Duringthis process, entity details may be provided, modified, and/or deletedin the system 10. For example, when a user in HR is adding a newemployee, the user may enter certain details of the employee, such asthe employee's name, start date, type of employment (full-time employee,part-time employee), address, and the like. In some embodiments, theuser may indicate a type of operation that is being requested, such ascreate, read, update, or delete. The information entered by the user maybe encapsulated into provisioning data 18 and sent to the provisioningsystem 14 (block 32), where the provisioning data 18 is received by theprovisioning system 14 (block 34).

Upon the occurrence of a trigger event, the provisioning system 14 maygenerate application specific content 20 (block 36). For example, insome embodiments, sending the provisioning data 18 to the provisioningsystem 14 may be considered a trigger event. Additional or alternativetrigger events may include a specific date, such as a start date, hiredate, etc., in the provisioning data 18, and when the specific datearrives, the provisioning system 14 may generate the applicationspecific content 20. Also, the trigger event may include pollingcontinuously for the receipt of the provisioning data 18, periodicallychecking for received provisioning data 18, and/or performing a batchoperation to check for received provisioning data 18 and generate theapplication specific content 20 when the provisioning data 18 is found.

To generate the application specific content 20, the system 10 mayenrich the provisioning data 18 by retrieving information already storedin the provisioning system 14 and/or retrieving the information from anexternal source. The provisioning system 14 may also convert theprovisioning data 18 into the application specific content 20 in acommon data format (e.g., extensible markup language (XML)),understandable by one or more of the applications 16. In someembodiments, the application specific content 20 may include substantialdetails related to the applications, the entity, and/or the account toprovision or de-provision.

Once the application specific content 20 is generated, the provisioningsystem 14 may provide the application specific content 20 to theapplications 16 (block 38), such that the applications 16 may receivethe application specific content 20 (block 40). For example, one or moreconnectors may be provided between the provisioning system 14 and theapplication 16. The connectors may provide a data pathway enabling datacommunication between provisioning system 14 and the applications 16.Thus, the application specific content 20 may be received by theapplication 16 via these connectors.

Upon receipt of the application specific content 20, the applications 16may implement the application specific content 20 (block 42).Implementing the application specific content 20 may include processingthe application specific content 20 and performing the operationsrequested/defined in the application specific content 20, such ascreating, updating, or deleting an account using the entity'sinformation (e.g., ID, name, etc.) and account information (e.g., SSOnumber, etc.), and/or creating, updating, or deleting access rightsusing the user's information (e.g., ID, name, etc.) and accountinformation (e.g., SSO number, etc.).

By using the process 30, the system 10 may enable streamlining andsimplifying the provisioning and de-provisioning of entities,application accounts, and access rights for the entities. For example,using a common provisioning/de-provisioning process 30 may enhance theefficiency, scalability, and maintainability of the system 10 byallowing a multitude of diverse feeds and/or applications 16 to beprovisioned and de-provisioned, without reliance on customizedprocedures for each data source and/or technology resource.

Turning now to a more detailed discussion of the provisioning system 14,FIG. 3 is a schematic view of provisioning components of theprovisioning system 14, in accordance with an embodiment. As shown inthe depicted embodiment, there may be any suitable number ofworkstations 12 communicably coupled to the provisioning system 14. Insome embodiments, the workstations 12 may provide the provisioning data18 to the provisioning system 14. For example, a workstation 12 user mayinput information (e.g., HR records, etc.) into an application of theworkstation 12, which may be provided to the provisioning system 14.

In some embodiments, the provisioning data 18 may be sent in alightweight data-interchange format, such as JavaScript object notation(JSON). The data-interchange format may include data in a collection ofname/value pairs that make up an object 50. In some embodiments, theobject 50 may be created upon the occurrence of a trigger event. Theobject 50 may be stored in one or more data repositories 52 accessibleby the provisioning system 14. As illustrated, the data repositories 52may be located locally (e.g., on the same server) to the provisioningsystem 14 and/or remotely (e.g., on a different server, such as on acloud environment) to the provisioning system 14.

The objects 50 may comply with a schema specification that defines theparticular data-interchange format. For example, the JSON object 50 maycomply with the system for cross-domain identity management (SCIM)standard. The schema may be platform neutral and enable representingentities and groups of entities in JSON and XML formats. Thus, due tothe schema's platform neutrality, the schema may enable efficientlymanaging entity identity and accounts in a provisioning system 14 thatinterfaces with numerous applications across different domains.

Depending on the type of request entered by the user or other system,creating the object 50 may correspond to creating a new account and/orentity, such as an employee, customer, contractor, system, or the like.The object 50 may be populated with information including account data56 and/or entity data 58. The account data 56 may relate to informationabout the application account (e.g., application account number,application name, attributes of the application account) for whichprovisioning and/or de-provisioning is being requested. The entity data58 may relate to information about the entity (e.g., entity ID number,entity type, address information, name, technology resource information(name, ID) when provisioning and/or de-provisioning a service account)for which provisioning and/or de-provisioning of data and/or technologyresources is being requested.

In some embodiments, the account data 56 and/or entity data 58 may beprovided by the user in the provisioning data 18. Further, this data maybe retrieved via one or more application programming interfaces (APIs)58 upon creation of the object 50.

The account data 54 returned from the APIs 58 may be encapsulated in apayload (body information of the object 50). The account data 54 mayinclude a single sign on (SSO) number for the application for which theprovisioned account is being requested, an application name for whichthe provisioned account is being requested, and/or one or moreattributes of the account, such as a status, a unit, and the like.

In some embodiments, the entity data 56 returned from the APIs 58 may beencapsulated in a payload. The entity data 56 may include an identity(ID) number of the entity, a type of entity, such as employee,contractor, customer, another computer system, or the like. Also, theentity data 56 may include a phone number, address, and so forth, forthe entity that accounts and/or access rights to applications are beingprovisioned or de-provisioned.

The APIs 58 may include hypertext transfer protocol (HTTP) web servicesthat adhere to representational state transfer (REST) architectureconstraints. The REST constraints may include using a base universalresource indicator (URI), an Internet media type for data, standard HTTPmethods, hypertext links to reference a state, hypertext links toreference related technology resources, and the like. The HTTP methodsused to implement the REST APIs 58 may include GET, PUT, POST, andDELETE methods, among others. For example, data may be fetched from therepositories 52 using the GET method, data may be replaced in therepositories 52 using the PUT method, new data may be created in therepositories 52 using the POST method, and data may be deleted from therepositories 52 using the DELETE method.

Once the data from the initial provisioning data 18 is populated in theobject 50, the object 50 may be converted/translated into a provisioningmessage 60. The provisioning message 60 may be represented in a textualdata format, such as the extensible markup language (XML). During thetranslation process, the provisioning message 60 may be enriched (e.g.,supplemented) with additional details, such as an owner of theprovisioned technology resources, and/or object type. Further, thegenerated provisioning message 60 may include markup of sections to befilled in by a rule based provisioning engine 62. For example, aprovisioning plan markup section may be provided in the provisioningmessage 60 that includes requestor details to be filled in by the rulebased provisioning engine 62. Enriching the provisioning message 60prior to executing operations against target applications may enablemore streamlined provisioning and de-provisioning of accounts forentities, by automatically gathering relevant provisioning informationwithout requiring manual intervention of a user.

After conversion/translation is complete, the provisioning message 60may be sent to the rule based engine 62 for further processing. The rulebased engine 62 may receive the provisioning message 60 and make aninitial determination as to whether the provisioning message 60 includesa request for an identity or for an account by calling one or more rules64. Based on the type of request (identity or account), the rule callsindicate how and when (e.g., under what conditions) to provision orde-provision the accounts for the data and/or technology resources. Insome embodiments, depending on the types of provisioning (e.g., tosoftware, content, etc.) the rules 64 may implement conventional digitalrights management (DRM) rules. In some embodiments, an example rule mayindicate that if the request is for a new ID or an existing ID, then therule based provisioning engine 62 takes different processing routes.Thus, provisioning and de-provisioning can be for new or existingentities. In either scenario, the rule based provisioning engine 62 mayenrich the provisioning message 60 with additional data 66. For example,as previously discussed, the provisioning plan markup section in theprovisioning message 60 may be populated with requestor detailsautomatically by the rule based provisioning engine 62.

If the request in the provisioning message 60 is for an identity, thenthe rule based engine 62 may determine the type of entity (contractor,employee, customer, etc.). The rule based engine 62 may perform a rule64 call by passing the type of entity and type of request. For example,if the type of request is an identity request (e.g., a request to createa new identity in the system 10) and the type of entity is an employeein the provisioning message 60, then the rule may result in employeecreation tasks (e.g., provisioning an email account, a VPN account, aparticular software suite account, read and write access rights to thefile share system, and so forth). As may be appreciated, the rule basedengine 62 may access numerous application connectors 68 to deliver andset up the provisioned applications (such as applications on theemployee's workstation). In some embodiments, the application connectors68 may translate the provisioning message 68 into formats that may beunderstood by the respective applications 16 and execute the operation(create, update, delete) calls against the target applications 16 toprovision or de-provision the accounts and/or access rights for theentity.

If the request in the provisioning message 60 is for new applicationaccounts for an existing identity, then the rule based engine 62 maymake rule 64 calls to determine what provisioning is allowed based onthe identity of the entity and the request type (e.g., what softwareapplications, access, or other provisions). For example, a contractormay be allowed to have accounts provisioned for a portion of theapplications of a software application suite but not all of theapplications. Depending on the rules, the appropriate applicationconnectors 68 are accessed to deliver and set up the provisioned items(such as applications on the employee's workstation).

FIGS. 4A and 4B illustrate a detailed schematic view of a provisioningsystem 10 including the rule based engine 62 and a message enrichmentprocess, in accordance with an embodiment. FIG. 5 is a flowchartillustrating a process 170 for provisioning data and/or technologyresources using the system 10 of FIGS. 4A and 4B including the rulebased engine 62 and the message enrichment process, in accordance withan embodiment. For clarity, FIGS. 4 and 5 will be discussed together.

The process 170 for provisioning data may begin with a trigger event 70(block 172), upon which an object 50 is created and stored (block 174).As previously discussed, the trigger event 70 may include populatingdata using a workstation 12. For example, a user of an HR system,identity management system, or the like, may request provisioning orde-provisioning by entering information about accounts for a new entityor existing entity (polling for information) on a workstation 12, aspecific date included with the entered information, such as a startdate, a time interval that checks for received information by theprovisioning system 14 (periodic basis), a batch process that findsentered information, and so forth.

Upon the trigger event 70, the object may be created, which maycorrespond, for example, to a new account/employee being created. Asillustrated, the trigger event 70 may cause one or more JSON objects 50to be created that include information about account data 54 forapplications and/or entity data 56.

The JSON objects 50 may include header and payload (body) information.The provisioning system 14 may call APIs 58 to retrieve the objects 50and to populate payload information for the objects 50 upon the triggerevent 70 occurring (block 176). For example, the account data 54 mayinclude a payload 72, which is illustrated in a JSON account object 73,that includes information about a single sign on (SSO) number for theapplication for which the provisioned account is being requested, anapplication name for which the provisioned account is being requested,and/or one or more attributes of the account, such as a status, a unit,and the like. The entity data 56 may include payloads for each entity,such as an employee payload 74, a customer payload 76, a contractorpayload 78, and the like. The information in the entity payloads 74, 76,and 78 may include an identity (ID) number of the entity, a type ofentity, such as employee, contractor, customer, another computer system,or the like, a phone number, an address, and so forth, as illustrated inthe JSON entity object 80. As should be understood, the appropriatepayload may be populated based on the type of entity for which theprovisioning or de-provisioning request is being made.

After the payloads 72, 74, 76, and/or 78 are populated with availableinformation, the process 170 may include validating the schema 82 of theobjects 50 (block 178). This validation may include checking that theinformation provided is accurate, such as ID information, name, phonenumber, application, etc., and verifies the data formatting of theobject 50 is correct.

After validation, the provisioning system 14 may use aconversion/translation service 84 to convert the payloads to aprovisioning message 60 (block 180). The provisioning message 60 may beconverted to a textual data-format such as XML. As illustrated, theprovisioning message 60, in some embodiments, may include elements for arequestor, operation, and request ID. Further, the provisioning message60 may include markup for an identity request/account request, which maybe populated based on whether the request is for an identity or anaccount. This identity request/account request may further includeelements for the entity type/account type and an ID. Embedded within theidentity request/account request markup may be markup for an attributerequest that includes elements for name, value, operation, and type. Aspreviously discussed, the provisioning message 60 may also include amarkup section for a provisioning plan where information about therequestor is provided later in the process 170. Theconversion/translation service 84 may send the provisioning message 60to the rule based provisioning engine 62.

In addition, a request service 85 may be running in the provisioningsystem 14 that may include functions for status tracking 88, errorhandling 90, and auditing 92. The status tracking 88 function maymonitor the status of the provisioning system 14. For example, in someembodiments, the statuses may include “object created,”“conversion/translation to XML complete,” “conversion/translation to XMLfailed,” “provisioning message sent to rule based provisioning engine,”and so forth. The error handling function 90 may mitigate errors thatoccur in the provisioning system 14. For example, if theconversion/translation to XML fails, the error handling function 90 mayattempt to resolve the issue or may catch any exceptions that are thrownby the provisioning system 14. The auditing 92 function may includeauditing the type and number of accounts that have been provisioned toentities, the number of applications available to be provisioned, thenumber of entities in the provisioning system 14, and so forth.

Upon receipt of the provisioning message 60, the rule based provisioningengine 62 may make an initial determination 94 of whether the request inthe provisioning message 60 is an identity request 96 or an accountrequest 98 (decision block 182) in a first phase of decisions. Thisinitial determination 94 may be thought of as an identity request 96 andaccount request 98 classification determination 86. The rule basedengine 62 may make this determination 94 by processing the provisioningmessage 60 and making one or more rule calls. In some embodiments, therule based provisioning engine 62 may make the rule calls using theentity ID and request type obtained from the provisioning message 60. Ifthe entity ID does not exist in an identity store 100 and the requesttype is for a new identity, then the rule may indicate that the requestis an identity request 96. If, on the other hand, the entity ID existsin the identity store 100 and the request type is for an additionalapplication account, then the rule may indicate that the request is anaccount request 98. In some cases, when de-provisioning an entity isrequested, the entity ID may exist in the identity store 100 but therequest type may be to delete the identity, and the rule may indicatethat the request is an identity request 96.

If the request is an identity request 96 to provision accounts for a newentity, the provisioning message 60 may be further enriched (e.g.,populated/supplemented) with information related to the requestor (block184) by making a “get requestor details” function call 102. As such, the“get requestor details” function call 102 may communicate with theidentity store 100 via an identity data access object 104. The identitydata access object 104 may include a component for a schemastandardization 106 function and a create, read, update, and delete(CRUD) connector 108. The CRUD connector 108 may use its read functionto obtain the requestor information from the identity store 100 and theschema standardization 106 function may normalize the data to be addedto the XML provisioning message 60. Then, the identity data accessobject 104 may return the requestor information to the rule basedprovisioning engine 62 in response to the “get requestor details”function call 102. The rule based provisioning engine 62 may populatethe provisioning plan markup section in the provisioning message 60 withthe requestor details.

Then, the provisioning message 60 may pass through a second phase ofdecisions, where a rule call determination 110 is made by the rule basedprovisioning engine 62 to determine which type of entity andapplications/access rights to provision to the entity (block 186). Thisrule call may indicate how to provision the entity's identity and whichapplications to provision to the entity based on the type of entity(contractor, employee, customer, etc.) and the request type in theprovisioning message 60. It should be noted that at this point, theenriched XML provisioning message 60 contains all the information neededto make choices on how to provision the accounts for the differententities using the rules. As may be appreciated, the fully enriched XMLprovisioning message 60 may enable streamlining the provisioning orde-provisioning process by capturing all needed data prior to actuallyexecuting the provisioning or de-provisioning.

In some embodiments, there may be different rules used for provisioningdifferent entity types, such as contractor provisioning 112, employeeprovisioning 114, customer provisioning 116, and so forth. Each type ofprovisioning 112, 114, and 116 may set up the identity of the entity inthe identity store 100 using the CRUD connector 108 of the identity dataaccess object 104. Further, each type of provisioning 112, 114, and 116may be provisioned different accounts based on the rule for thatparticular entity type and request type. As a result, there may beapplication connectors (app A connector 118, app B connector 120) thatare accessed if the rule indicates that the particular type of entitytype provisioning should be provisioned that application account. Forexample, the rule for employee provisioning 114 may indicate that theemployee should be provisioned an application account for email andvirtual private network (VPN), which may correspond to the app Aconnector 118 and app B connector 120, respectively. On the other hand,the rule for contractor provisioning 114 may indicate that thecontractor should be provisioned only an account for email and, thus,only access app A connector 118. It should be appreciated that theapplication connectors may correspond to any data source and/ortechnology resource (e.g., any software application, database, fileshare system, network, or the like). As previously discussed, theapplication connectors may be used to execute the provisioning to thetarget applications 16 (arrow 122) by delivering and setting up theprovisioned applications 16 (such as applications on the employee'sworkstation). That is, the application connectors may perform create,update, or delete functions for accounts associated with the desiredapplications 16.

Returning to the initial determination 94 and focusing now on theaccount request 98 flow of events. In some embodiments, the rule basedprovisioning engine 62 may determine that the request in theprovisioning message 60 is an account request 98 (decision block 182) inthe first phase of decisions based on the rule call. The rule call mayindicate that the request is an account request 98 when the entity IDexists in the identity store 100 and the request type is for anadditional application to be provisioned to the entity.

Once determined to be an account request 98, the provisioning message 60may be further enriched with information about the entity's identity(block 190). For example, the rule based provisioning engine 62 may makea “get identity details” function call 124. As such, the “get identitydetails” function call 124 may communicate with the identity store 100via the identity data access object 104. The CRUD connector 108 may useits read function to obtain the identity information from the identitystore 100 and the schema standardization 106 function may normalize thedata to be added to the XML provisioning message 60. Then, the identitydata access object 104 may return the identity information to the rulebased provisioning engine 62 in response to the “get identity details”function call 124. The rule based provisioning engine 62 may populatethe identity markup section in the provisioning message 60 with theidentity details. The identity details may include the entity ID, theaccounts provisioned to the identity, and so forth.

Then, the provisioning message 60 may pass through the second phase ofdecisions, where the rule based provisioning engine 62 may make adetermination 126 of what additional application accounts and/or accessrights to provision to the existing entity based on rule calls (block192). The rule call may indicate the applications to provision based onthe entity ID, entity type, request type, or some combination thereof.For example, a certain entity type, such as a contractor, may beprovisioned a subset of a software application suite but not all of thesoftware applications in the suite. Further, the request may be toprovision an account that is prohibited for the entity's type and therule call may indicate that the desired application account is notallowed for that entity type.

Based on the rule calls, the rule based provisioning engine 62 maymodify the provisioning message 60 with the application accountinformation to be provisioned (e.g., app C provisioning 128, app Dprovisioning 130). In some embodiments, accounts and/or access rightsmay be provisioned for: word processing software applications, payrollapplications, software development applications, or any other suitablesoftware application. After the account provisioning information hasbeen set up, the rule based provisioning engine 62 may access theapplication connectors (e.g., app C connector 132, app D connector 134)to execute the provisioning (block 192). That is, the applicationconnectors may be used to execute the provisioning to the targetapplications 16 (arrow 122) by delivering and setting up the provisionedapplications 16 to the entity (such as applications on the employee'sworkstation). Further, in some embodiments, the application connectorsmay perform conversion/translations of the XML provisioning message 60to a data-format understood by the particular applications 16 to beprovisioned.

It should be noted that, in some embodiments, the account request 98provisioning may also be accessed by looping back from the entity typeprovisioning 112, 114, and 116 performed for identity requests 96, asillustrated by dashed arrow 136. For example, a rule may indicate duringa particular entity type provisioning 112, 114, and 116 that the entityshould be provisioned an account for an application not included in astandard set of initial data and/or technology resources to provision.Thus, the rule based provisioning engine 62 may invoke the accountrequest 98 provisioning to provision the additional account. Toillustrate, a rule may indicate that an employee entity type should beprovisioned app A (e.g., email), app B (e.g., VPN), and app C (e.g.,word processing application software). As depicted, an employee beingprovisioned for the first time only has access to the app A (e.g.,email) connector 118 and app B (e.g., VPN) connector 120. Therefore, therule based processing engine 62 may invoke account request 98provisioning (dashed arrow 136) to access the app C (e.g., wordprocessing application software) provisioning 128 and the app Cconnector 128.

The rule based provisioning engine 62 may use a framework that includescomponents for email notification 138, auditing/logging 140, errorhandling 142, and message management 144. The email notificationcomponent 138 may send emails to the administrators of the provisioningsystem 14, developers of the provisioning system 14, or the like, ifthere are issues that arise during operation, such as errors. Theauditing/logging component 140 may log the activity rule basedprovisioning engine 62. For example, the auditing/logging component 140may log the flow of messages in and out of the rule based provisioningengine 62 including timestamps. The auditing/logging component 140 mayalso log any errors that occur with the rule based provisioning engine62.

The error handling component 142 may catch any exceptions that arethrown while the rule based provisioning engine 62 is executing andperform remedial measures. The message management component 144 maymanage the flow of messages in and out of the rule based provisioningengine 62. For example, if an unusually large number of messages arereceived by the rule based provisioning engine 62 at substantially thesame time, the message management component 144 may use an algorithm tomoderate the flow of messages so as not to greatly disturb theprocessing speed of the rule based provisioning engine 62. Moreover, themessage management component 144 may resend messages if the messagesstall or fail to send.

While only certain features of the present disclosure have beenillustrated and described herein, many modifications and changes willoccur to those skilled in the art. It is, therefore, to be understoodthat the appended claims are intended to cover all such modificationsand changes as fall within the true spirit of the present disclosure.

1. A computer-implemented method, comprising: creating one or moreobjects in response to a trigger event; converting the one or moreobjects to a provisioning message; determining whether the provisioningmessage includes a request for an identity or an account using one ormore rule calls; when the request is for the identity, determining atype of entity to provision and application accounts to provision forthe entity using one or more rule calls; when the request is for theaccount, determining which application accounts to provision for theentity using one or more rule calls; and provisioning the applicationaccounts for the entity as determined.
 2. The computer-implementedmethod of claim 1, comprising: providing, via the one or more rulecalls, provisioning rules based on the entity's identity and requesttype in the provisioning message.
 3. The computer-implemented method ofclaim 2, comprising: indicating, in the one or more rule calls, that therequest is for the identity when the entity's identity does not exist inan identity data store and the request type is to create a new identity.4. The computer-implemented method of claim 2, comprising: indicating,in the one or more rule calls, that the request is for the account whenthe entity's identity exists in an identity data store and the requesttype is to provision a new application account, access rights, or both.5. The computer-implemented method of claim 1, comprising: defining theone or more objects in a JavaScript object notation (JSON) data-formatand defining the provisioning message in an extensible-markup language(XML) data-format.
 6. The computer-implemented method of claim 1,comprising: populating the one or more objects with account and entityinformation using a web service prior to conversion to the provisioningmessage.
 7. The computer-implemented method of claim 1, comprising:populating the provisioning message with requestor information when therequest is for the identity and with identity information when therequest is for the account.
 8. The computer-implemented method of claim1, comprising: indicating, via the one or more rule calls used whendetermining the type of entity to provision and application accounts toprovision for the entity, which application accounts to provision basedon the type of entity and request type.
 9. The computer-implementedmethod of claim 1, comprising: looping back to the request for theaccount when the one or more rule calls indicates an additional accountis to be provisioned to the type of entity being provisioned.
 10. Thecomputer-implemented method of claim 1, comprising: accessing one ormore application connectors to deliver and set up the provisionedapplication accounts.
 11. The computer-implemented method of claim 1,comprising: when the request is for the identity, determining a type ofentity to de-provision and application accounts to de-provision for theentity using one or more rule calls; when the request is for theaccount, determining which application accounts to de-provision for theentity using one or more rule calls; and de-provisioning the applicationaccounts for the entity as determined.
 12. A system, comprising: aprocessor-based workstation; a processor-based provisioning system; oneor more data sources, technology resources, or both; wherein theprocessor-based provisioning system is configured to: create one or moreobjects in response to a trigger event activated by the processor-basedworkstation; convert the one or more objects to a provisioning message;determine whether the provisioning message includes a request for anidentity or an account for the one or more data sources, technologyresources, or both using one or more rule calls; when the request is forthe identity, determine a type of entity to provision and accounts,access rights, or both for the one or more data sources, technologyresources, or both to provision for the entity using one or more rulecalls; when the request is for the account for the one or more datasources, technology resources, or both, determine which of the one ormore data sources, technology resources, or both accounts, accessrights, or both to provision for the entity using one or more rulecalls; and provision the one or more data sources, technology resources,or both accounts, access rights, or both for the entity as determined.13. The system of claim 12, wherein provisioning accounts for the one ormore data sources, technology resources, or both for the entitycomprises accessing a respective connector for the data sources,technology resources, or both to setup the account for the data sources,technology resources, or both, and deliver the accounts, software, orboth, for the data sources, technology resources, or both to aworkstation of the entity.
 14. The system of claim 12, wherein theprovisioning message is populated with information related to arequestor of the provisioning, the identity of the entity to beprovisioned, an operation to be performed during the provisioning, orsome combination thereof, prior to being sent to connectors for the oneor more data sources, technology resources, or both to be provisioned.15. The system of claim 14, wherein the requestor information isobtained from an identity store when it is determined that the requestis for the identity.
 16. The system of claim 14, wherein the identityinformation of the entity is obtained from an identity store when it isdetermined that the request is for the account.
 17. The system of claim12, wherein the one or more objects are populated with account andentity information using a web service prior to conversion to theprovisioning message.
 18. A processor-based device, configured to:create one or more objects in response to a trigger event; convert theone or more objects to a provisioning message; determine whether theprovisioning message includes a request for an identity or an accountusing one or more rule calls; when the request is for the identity,determine a type of entity to provision and accounts to provision forthe entity using one or more rule calls; when the request is for theaccount, determine which of the accounts to provision for the entityusing one or more rule calls; and provision the accounts for the entityas determined.
 19. The processor-based device of claim 18, wherein therule call used when determining whether the provisioning messageincludes the request for the identity or the account is based on anentity identification and a request type.
 20. The processor-based deviceof claim 19, wherein the one or more objects comply with a standard forcross-domain identity management (SCIM) schema, wherein the schema isplatform neutral and the objects represents the entity, a group ofentities, or both in JavaScript objec notation (JSON) andextensible-markup language formats (XML).